Since the Network File System (NFS) protocol was developed in 1984, users of client devices have been able to access files over a network in a manner similar to how local storage is accessed. A basic premise behind NFS is a simple client/server model. Directories on an NFS server are shared, an NFS client mounts those directories, and then it appears to the user(s) on the client machine as just another file system.
The following is an example of a typical Unix-style scenario in which one machine (the client) requires access to data stored on another machine (the NFS server). First, the NFS server implements NFS daemon processes (running by default as nfsd) in order to make its data generically available to clients. Second, an administrator determines what data to make available by exporting the names and parameters of directories (typically using the /etc/exports configuration file and the exportfs command). Third, security administration of the NFS server ensures that it can recognize and approve validated clients. Fourth, network configuration of the NFS server ensures that appropriate clients can negotiate with the NFS server through any firewall system. Fifth, a client machine requests access to exported data, typically by issuing a mount command. This step may involve the NFS client asking the NFS server (using rpcbind) which port the NFS server is using, the NFS client connecting to the NFS server (using nfsd), and nfsd passing the request to mountd. If each step succeeds, users of the client machine can then view and interact with mounted file systems on the NFS server within the parameters permitted.
Current network file servers export file systems to many clients. These file systems are limited in availability in that, when a node serving the file system goes down, no new requests are serviced until the node comes back up and begins to serve the file system again. In one possible approach for providing a high available network file system, two nodes each serve different file systems. If one node goes down, then the other node assumes the export of the failed node's file system(s). However, a NFS client must be configured to mount the same file system through multiple nodes. This is referred to as “multiple mount points.” In this way, a NFS client must be configured to know when a node goes down in order to attempt accessing the same data through another mount point (i.e., the other node).
In addition, nodes can easily get overloaded processing I/O from clients. Since I/O may take over the system, using all available network and storage bandwidth, other clients may find themselves starved for I/O, waiting for small windows of time to get the information they need back from the network file server. There are no known highly available solutions that provide performance adjustment and load balancing.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.